home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Atari Compendium
/
The Atari Compendium (Toad Computers) (1994).iso
/
files
/
umich
/
telecomm
/
fnordadl
/
fn132man.zoo
/
chapter.10
< prev
next >
Wrap
Text File
|
1991-09-02
|
27KB
|
572 lines
Chapter 10: Anti-Ruggie Measures 133
10 Anti-Ruggie Measures
__Ruggie__ is short for ``rug-rat''; it's a somewhat mutated term which
now refers to any brat, twit, twerp, loser, wanker, nud, idiot, len, moron,
or generally, any walking waste of protoplasm. These types of people
(often, though by no means exclusively, kids who've just been given their
first modem for Christmas) may suddenly spring up and begin to plague your
BBS. They may do any one of a number of things, from logging in and asking
stupid questions, to putting drivel in the discussion rooms, to strewing
megabytes of profanity all over your board. If they do the former, then
you may simply want to take them aside, so to speak, and answer their
questions. If they do something like the latter, then read on.
10.1 Philosophy
``But first, a brief philosophical interlude.'' The developers of
Fnordadel have been running conversation-only BBSes for a number of years
(the Round Table, Royce's board, went up in August of 1984, and Secret
Service, Adrian's board, has been around since March of 1986). In all that
time, a philosophy of ``open'' Sysoping has prevailed. That is, we've
always disliked the validation style of BBSes---the kind where you have to
leave ten pages of personal information before the Sysop will grant you
access to his system. We prefer to run systems where anyone can create a
new account at any time, without Sysoply intervention, and then dive into
most of what goes on with the system.
The problem with this, of course, is that undesirables tend to slip in.
Any ruggie can call in and leave his drivel or profanity at any time, and
there ain't much that the Sysop can do about it. About the most he can
do, on a standard Citadel, is delete the offending messages as soon as he
sees them, hopefully before they got sent anywhere if the rooms affected
are networked, and pray the ruggie doesn't call back. Or he can turn
his system into a ``closed'', validation-style system, which may not be an
attractive option. It certainly isn't to us.
Here in Edmonton, we've had a pretty determined gang of ruggies plaguing
the boards for a couple of years, and it was primarily these twits who
prompted the development of Fnordadel's anti-ruggie features which aren't
found on other Citadels.
*Please note:* no security measures ever devised can stop a determined
incursion, so we advise you to be pretty low-key about what security
measures you may have in place, to avoid tempting people to break them.
Chapter 10: Anti-Ruggie Measures 134
10.2 The Secret Weapons
Here, then, are the tools at your disposal. Use any combination that
works for you without causing your regular users undue discomfort.
10.2.1 Paranoid mode
Standard Fnordadel requires that users login using their password only;
if people are intelligent in choosing their passwords, this works fine and
is quicker than having to type in one's user name as well. Unfortunately,
many people are not the least bit intelligent when it comes to password
choosing (or anything else, for that matter), so it leaves a resourceful
ruggie with some golden opportunities to hack someone's account and cause
chaos.
If you define the variable #getname to have the value `1' in your
`ctdlcnfg.sys' (referred to in the literature as ``paranoid mode'', for
hysterical... err... historical reasons), Fnordadel will ask for both a
name and a password when logging users in. This means that a ruggie has to
guess not only a user's password, but to which user the password belongs.
This is pretty tough.
10.2.2 Messages per room per call
A favourite ruggie trick is to use an automated macro to enter one
message (frequently something short but obscene) into one or more rooms,
over and over and over again; the goal being to scroll all the real
messages out of your message base.
To combat this, Fnordadel allows you to define the maximum number of
messages which any given user can enter in any given room during any one
login session. (The Mail> room is an exception; see the next section.)
Simply define the `ctdlcnfg.sys' variable #msgenter to be your desired
maximum. For most systems, a number like `4' or `5' is pretty good; it
allows the legitimate users plenty of leeway for verbosity, while helping
to contain the damage done by a vandal. Deleting 4 or 5 messages from a
few rooms is much better than deleting hundreds, or having to nuke your
message base because it's full of ``Sysop Sucks Eggs'' messages.
Setting this parameter to `0' means there is no limit on the number of
messages enterable by anybody. Even if the value is non-zero, all Aides,
Co-Sysops and the Sysop are exempt from the limit. Hopefully you won't all
run wild.
Chapter 10: Anti-Ruggie Measures 135
10.2.3 Mail messages per call
The parameter #mailenter in `ctdlcnfg.sys' works exactly like its
counterpart msgenter described above. It controls only the Mail> room,
however, and thus allows you to independently alter users' use of private
mail. Not only can this be used to stop vandals from flooding your decent
users with junk mail, it can be used to control non-ruggies who may be a
bit too enthusiastically posting private messages.
Again, setting this parameter to `0' means there is no limit on the
number of messages enterable by anybody. Aides, Co-Sysops and the Sysop
are exempt from the limit in any case.
Another parameter to consider in this area is allmail. If set to `1',
the parameter allows all users full access to entering messages in the
Mail> room. If set to `0', however, users are not able to enter mail to
anybody except `Sysop', unless you manually give them mail privileges (see
Section 5.2 [User Status Commands], page 80). Naturally, Aides, Co-Sysops
and the Sysop always have full Mail> access. See `flipbits.man' if you
need a way to set the mail access flag for all users in one swell foop.
10.2.4 Maximum number of calls per day
This parameter is called #maxcalls in `ctdlcnfg.sys', and is used to
limit the total number of calls any user (except Aides, Co-Sysops and the
Sysop, of course) may make in a given day. Again, setting the parameter to
`0' means there is no limit.
10.2.5 Maximum connect time per day
This parameter is called #maxtime in `ctdlcnfg.sys', and is used to
limit the total connect time any user (except Aides, Co-Sysops and the
Sysop, of course) may use up in a given day. The value is in minutes.
Again, setting the it to `0' means there is no limit.
This measure is like the others, in that it is non-intrusive---users
will not be booted off the system the second they exceed their daily
allotment of connect time. Instead, they will be allowed to finish their
current login session. But if they call back the same day, they will not
be permitted entry. This seems to us like a good mix of control for the
Sysop vs. consideration for the users.
A related parameter that you might want to look at is mincalltime. This
value is in minutes, and specifies the minimum connect time you wish to
``charge'' a user on any call, no matter how short it is. (For example,
if you set this variable to `5', all calls of five minutes or less will
be charged as five minutes.) The lowest acceptable value is `1', but you
can set it higher if you're concerned about users that call frequently but
spend very little time connected.
Chapter 10: Anti-Ruggie Measures 136
10.2.6 Maximum number of close calls per day
Now we get really tricky. First of all, you say, ``What the heck is a
`close call'? I just about got hit by a truck, is that what you mean?